Extending wolfIP AMD FPGA example support for full wolfBoot demo - #137
Extending wolfIP AMD FPGA example support for full wolfBoot demo#137dgarske wants to merge 6 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
Extends the AMD/Xilinx bare-metal wolfIP examples to support a full wolfBoot demo flow: running at EL2 when chain-loaded by wolfBoot, adding a ZC702 DDR memory layout option, and enabling SD-card based OTA updates on ZCU102 via TFTP + wolfBoot’s disk/SDHCI drivers compiled into the app.
Changes:
- Add Zynq-7000 DDR linker script +
LAYOUT=ocm|ddrselection to improve ZC702 throughput and support wolfBoot load address. - Add ZCU102
EL=2|3selection (EL2 chain-load support) and adjust AArch64 startup/MMU code for EL2 system registers. - Add ZCU102 OTA path (
OTA=1) with SDHCI shim, newlib syscall stubs, and a TFTP-based update stager writing OFP_B then resetting.
Reviewed changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
src/port/amd/README.md |
Updates performance table and loading notes reflecting ZC702 DDR support. |
src/port/amd/common/app.c |
Adds optional OTA trigger via UDP “UPDATE” and calls ota_poll() in main loop. |
src/port/amd/boards/zynq7000/target_ddr.ld |
New DDR-based linker layout aligned to wolfBoot load address. |
src/port/amd/boards/zynq7000/Makefile |
Adds LAYOUT selector and rebuild-stamp handling for layout switches. |
src/port/amd/boards/zcu102/syscalls_stub.c |
New minimal newlib syscall stubs for OTA builds pulling in snprintf(). |
src/port/amd/boards/zcu102/sdhci_shim.c |
New glue layer to reuse wolfBoot SDHCI/disk drivers inside the wolfIP app + reset hook. |
src/port/amd/boards/zcu102/ota.h |
Declares OTA trigger/poll API used by the common app. |
src/port/amd/boards/zcu102/ota.c |
Implements TFTP download → RAM staging → OFP_B write → reset sequencing. |
src/port/amd/boards/zcu102/Makefile |
Adds EL selector and OTA=1 build path pulling in wolfBoot driver sources. |
src/port/amd/boards/zcu102/board.c |
Updates banner to reflect whether running at EL2 or EL3. |
src/port/amd/arch/armv7/mmu_armv7.c |
Carves DDR cacheability around DMA buffer region when DMA buffers live in DDR. |
src/port/amd/arch/aarch64/startup_aarch64.S |
Retargets EL-specific system registers for EL2 chain-loaded entry. |
src/port/amd/arch/aarch64/mmu_aarch64.c |
Retargets MMU control registers/TLB ops for EL2 vs EL3 builds. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
2001571 to
42698fa
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 20 out of 20 changed files in this pull request and generated no new comments.
Suppressed comments (2)
src/port/amd/boards/zcu102/wolfboot-demo/build.sh:42
- The demo build checks only for zynqmp_fsbl.elf, but bootgen also needs pmufw.elf and bl31.elf. If either is missing, the script will run further and then fail later with a less actionable error. Add explicit checks for all three firmware components up front.
[ -f "$FW/zynqmp_fsbl.elf" ] || { echo "ERROR: FSBL/PMUFW/BL31 not in $FW - build them (see README) and set FW=" >&2; exit 1; }
src/port/amd/boards/zcu102/syscalls_stub.c:96
- _fstat() currently returns success even when passed a NULL stat pointer, which violates the usual newlib syscall contract and can make callers think the fd is valid when no data was written. Return -1 with errno=EINVAL when st is NULL (consistent with other ports’ syscalls.c).
if (st != NULL)
st->st_mode = S_IFCHR;
return 0;
AMD/Xilinx ZCU102: EL2 chain-load, SD-card OTA, and wolfBoot secure-boot demo
Extends the AMD/Xilinx wolfIP ports with wolfBoot chain-loading support, an on-device SD-card OTA update path for the ZCU102, and an end-to-end secure-boot + OTA demo.
What this does
src/port/amd/boards/zcu102/wolfboot-demo/): a self-contained walkthrough plus scripts that build wolfBoot for the ZynqMP SD config, sign the app v1/v2 (RSA-4096 / SHA3), assembleBOOT.BIN(FSBL + PMUFW + BL31 + wolfBoot), program an SD card, and apply a signed A/B firmware update fetched over TFTP.The demo
Lives under the ZCU102 port as
wolfboot-demo/and is the secure-boot variant of the boot flow (FSBL -> PMUFW -> BL31 -> wolfBoot (EL2) -> signed app (EL2)), distinct from the port's stockFSBL -> appchain (bootgen/,flash_sd.sh). It builds the app in the parent directory with theOTA=1 EL=2 LAYOUT=ddroptions added by this PR, and drives an external wolfBoot checkout (WOLFBOOT=, default../wolfBoot) to sign the image and generate the boot image. The running app fetches a newer signed image over the network, writes it to theOFP_BSD partition, and resets; wolfBoot then verifies both slots and boots the higher version, rolling back if the update fails to verify.What makes it notable: the app re-uses wolfBoot's own SD-host and disk drivers (
sdhci.c,disk.c,gpt.c) compiled straight into the application via a small EL2 platform shim (sdhci_shim.c), so one driver serves both wolfBoot and the app with no runtime hand-off.Files added:
build.sh- build wolfBoot + sign the app v1/v2 + assembleBOOT.BINpartition-sd.sh/program-sd.sh- create the demo MBR layout and program a cardupdate.sh- stage the update image + trigger the OTA over the networkboot.bif.in- bootgen template for the wolfBoot chainREADME.md- full walkthrough with expected console outputDependencies
aarch64-none-elf-GCC andbootgen(Vitis) onPATH. FSBL/PMUFW/BL31 are board-specific (AMD prebuilts or a local Vitis/PetaLinux/ATF build).Testing
OFP_B, resets, and wolfBoot boots the higher version; a tampered image fails verification and the board stays on v1.bash -nclean and fail-fast on missing dependencies.